提到專案管理，我以前最先想到的是排時程、追進度，還有那些彷彿永遠開不完的會。真正參與軟體開發後，我才發現，這些只是最容易被看見的部分。真正困難的是：時間、預算和人力都有限，團隊仍要對「到底要完成什麼」有共同理解，遇到變動時也知道該怎麼調整。
根據 Project Management Institute（PMI）的說明，專案是一項有明確起點與終點的工作，目的是產生獨特的產品、服務或成果；專案管理則是運用知識、技能、工具與方法，讓專案達成需求。它並非只用在委外開發或大型工程。公司導入新系統、替網站增加會員功能，甚至籌辦一場技術活動，都可以視為專案。
專案和日常營運也不太一樣。客服每天回覆問題，屬於持續進行的工作；開發一套客服工單系統，則有預定成果與交付時間。系統上線後，建置專案告一段落，後續的維護與客服才進入日常營運。
圖中的工作看板只是團隊協作的一部分；周圍的時程、預算、人力、風險與決策取捨，才是專案管理每天需要面對的全貌。
假設客戶只說：「我想要一套專案管理網站。」如果團隊立刻開始寫程式，每個人想像的成品可能完全不同。有人先做登入，有人認為甘特圖最重要，也有人直接開始設計資料庫。大家都很忙，最後做出的功能卻未必能解決使用者的問題。
專案管理要先做的，是把模糊的想法整理成可以討論、也能驗收的內容。系統給誰使用？第一版要做哪些功能？哪些需求暫時不做？做到什麼程度才算完成？這些問題有了答案，團隊才能估算時程、安排工作，並找出彼此牽動的任務。
實際開發很少會一路照表操課。需求可能改變，第三方服務可能中斷；原本以為半天就能寫完的功能，動手後才發現比預期麻煩。風險管理不是要猜中所有意外，而是提早記下已經想到的問題、評估影響，再準備可以接受的處理方式。狀況真的發生時，團隊才能據此決定要縮小範圍、調整時程或增加資源，不必等到交付前一天才承認來不及。
專案經理通常負責整合資訊與協調資源，但專案能否順利完成，仍取決於整個團隊。工程師需要說明技術限制與實際進度，設計師要確認操作流程，需求提出者也得參與取捨與驗收。
我後來覺得，專案資訊透明，比「看起來一切順利」有用得多。工作卡住時及早說明，團隊還有時間一起處理；如果每個人都等到最後才回報，再好的工具也救不了進度。固定且簡短的同步、清楚的任務狀態與決策紀錄，可以減少團隊對口頭記憶的依賴。
市面上已經有許多成熟的專案管理服務。對大多數團隊來說，直接採用通常比較快，也省得自行維護。自建系統可不是免費：開發、測試、主機、備份、安全更新與後續支援，每一項都是成本。Microsoft 的架構指引也建議，評估自建或採購時，應一起比較上市時間、團隊的技術能力、持續維護與整體成本，不能只看授權費。
那這個系列為什麼還要做一套？我不是想取代成熟產品，而是想透過一個大家都看得懂的題目，完整練習需求整理、架構設計、前後端開發、自動化測試與部署。自己動手做，也比較容易看見權限、工作流程與 API 契約之間如何互相影響。
如果是真實公司的案子，我不會因為想練技術，就建議把所有功能都自己做。現成工具無法配合特殊流程、整合需求或資料治理規範，而且長期效益確實高於總成本時，自建才是合理的選項。
下一篇會再往前走一步。面對「做一套專案管理網站」這種仍然模糊的目標，我們可以怎麼用運算思維把它拆開，整理成能動手解決的問題。
iThome鐵人賽
看影片追技術